home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc1309.txt < prev    next >
Text File  |  1994-08-01  |  36KB  |  899 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          C. Weider
  8. Request for Comments: 1309                                           ANS
  9. FYI: 14                                                      J. Reynolds
  10.                                                                      ISI
  11.                                                                 S. Heker
  12.                                                                     JvNC
  13.                                                               March 1992
  14.  
  15.  
  16.                 Technical Overview of Directory Services
  17.                         Using the X.500 Protocol
  18.  
  19. Status of this Memo
  20.  
  21.    This memo provides information for the Internet community. It does
  22.    not specify an Internet standard.  Distribution of this memo is
  23.    unlimited.
  24.  
  25. Abstract
  26.  
  27.    This document is an overview of the X.500 standard for people not
  28.    familiar with the technology. It compares and contrasts Directory
  29.    Services based on X.500 with several of the other Directory services
  30.    currently in use in the Internet. This paper also describes the
  31.    status of the standard and provides references for further
  32.    information on X.500 implementations and technical information.
  33.  
  34.    A primary purpose of this paper is to illustrate the vast
  35.    functionality of the X.500 protocol and to show how it can be used to
  36.    provide a global directory for human use, and can support other
  37.    applications which would benefit from directory services, such as
  38.    main programs.
  39.  
  40.    This FYI RFC is a product of the Directory Information Services
  41.    (pilot) Infrastructure Working Group (DISI).  A combined effort of
  42.    the User Services and the OSI Integration Areas of the Internet
  43.    Engineering Task Force (IETF).
  44.  
  45. 1.  INTRODUCTION
  46.  
  47.    As the pace of industry, science, and technological development
  48.    quickened over the past century, it became increasingly probable that
  49.    someone in a geographically distant location would be trying to solve
  50.    the same problems you were trying to solve, or that someone in a
  51.    geographically distant location would have some vital information
  52.    which impinged on your research or business.  The stupendous growth
  53.    in the telecommunications industry, from telegraphs to telephones to
  54.    computer networks, has alleviated the problem of being able to
  55.  
  56.  
  57.  
  58. DISI Working Group                                              [Page 1]
  59.  
  60. RFC 1309              Technical Overview of X.500             March 1992
  61.  
  62.  
  63.    communicate with another person, PROVIDED THAT YOU KNOW HOW TO REACH
  64.    THEM.
  65.  
  66.    Thus, along with the expansion of the telecommunications
  67.    infrastructure came the development of Directory Services. In this
  68.    paper, we will discuss various models of directory services, the
  69.    limitations of current models, and some solutions provided by the
  70.    X.500 standard to these limitations.
  71.  
  72. 2  MODELS OF DIRECTORY SERVICES
  73.  
  74. 2.1  The telephone company's directory services.
  75.  
  76.    A model many people think of when they hear the words "Directory
  77.    Services" is the directory service provided by the local telephone
  78.    company. A local telephone company keeps an on-line list of the names
  79.    of people with phone service, along with their phone numbers and
  80.    their address. This information is available by calling up Directory
  81.    Assistance, giving the name and address of the party whose number you
  82.    are seeking, and waiting for the operator to search his database. It
  83.    is additionally available by looking in a phone book published yearly
  84.    on paper.
  85.  
  86.    The phone companies are able to offer this invaluable service because
  87.    they administer the pool of phone numbers. However, this service has
  88.    some limitations. For instance, you can find someone's number only if
  89.    you know their name and the city or location in which they live. If
  90.    two or more people have listings for the same name in the same
  91.    locality, there is no additional information which with to select the
  92.    correct number. In addition, the printed phone book can have
  93.    information which is as much as a year out of date, and the phone
  94.    company's internal directory can be as much as two weeks out of date.
  95.    A third problem is that one actually has to call Directory assistance
  96.    in a given area code to get information for that area; one cannot
  97.    call a single number consistently.
  98.  
  99.    For businesses which advertise in the Yellow Pages, there is some
  100.    additional information stored for each business; unfortunately, that
  101.    information is unavailable through Directory Assistance and must be
  102.    gleaned from the phone book.
  103.  
  104. 2.2 Some currently available directory services on the Internet.
  105.  
  106.    As the Internet is comprised of a vast conglomeration of different
  107.    people, computers, and computer networks, with none of the hierarchy
  108.    imposed by the phone system on the area codes and exchange prefixes,
  109.    any directory service must be able to deal with the fact that the
  110.    Internet is not structured; for example, the hosts foo.com and
  111.  
  112.  
  113.  
  114. DISI Working Group                                              [Page 2]
  115.  
  116. RFC 1309              Technical Overview of X.500             March 1992
  117.  
  118.  
  119.    v2.foo.com may be on opposite sides of the world, the .edu domain
  120.    maps onto an enormous number of organizations, etc.  Let's look at a
  121.    few of the services currently available on the Internet for directory
  122.    type services.
  123.  
  124. 2.2.1 The finger protocol.
  125.  
  126.    The finger protocol, which has been implemented for UNIX systems and
  127.    a small number of other machines, allows one to "finger" a specific
  128.    person or username to a host running the protocol. This is invoked by
  129.    typing, for example, "finger clw@mazatzal.merit.edu". A certain set
  130.    of information is returned, as this example from a UNIX system finger
  131.    operation shows, although the output format is not specified by the
  132.    protocol:
  133.  
  134.       Login name: clw                   In real life: Chris Weider
  135.       Directory: /usr/clw               Shell: /bin/csh
  136.       On since Jul 25 09:43:42          4 hours 52 minutes Idle Time
  137.       Plan:
  138.       Home: 971-5581
  139.  
  140.    where the first three lines of information are taken from the UNIX
  141.    operating systems information and the line(s) of information
  142.    following the "Plan:" line are taken from a file named .plan which
  143.    each user modifies.  Limitations of the fingerd program include: a)
  144.    One must already know which host to finger to find a specific person,
  145.    b) since primarily UNIX machines run fingerd, people who reside on
  146.    other types of operating systems are not locateable by this method,
  147.    c) fingerd is often disabled on UNIX systems for security purposes,
  148.    d) if one wishes to be found on more than one system, one must make
  149.    sure that all the .plan files are consistent, and e) there is no way
  150.    to search the .plan files on a given host to (for example) find
  151.    everyone on mazatzal.merit.edu who works on X.500.  Thus, fingerd has
  152.    a limited usefulness as a piece of the Internet Directory.
  153.  
  154. 2.2.2 whois
  155.  
  156.    The whois utility, which is available on a wide of variety of
  157.    systems, works by querying a centralized database maintained at the
  158.    DDN NIC, which was for many years located at SRI International in
  159.    Menlo Park, California, and is now located at GSI. This database
  160.    contains a large amount of information which primarily deals with
  161.    people and equipment which is used to build the Internet.  SRI (and
  162.    now GSI) has been able to collect the information in the WHOIS
  163.    database as part of its role as the Network Information Center for
  164.    the TCP/IP portion of the Internet.
  165.  
  166.    The whois utility is ubiquitous, and has a very simple interface. A
  167.  
  168.  
  169.  
  170. DISI Working Group                                              [Page 3]
  171.  
  172. RFC 1309              Technical Overview of X.500             March 1992
  173.  
  174.  
  175.    typical whois query look like:
  176.  
  177.       whois Reynolds
  178.  
  179.    and returns information like:
  180.  
  181.       Reynolds, John F. (JFR22) 532JFR@DOM1.NWAC.SEA06.NAVY.MIL
  182.                                            (702) 426-2604 (DSN) 830-2604
  183.       Reynolds, John J. (JJR40) amsel-lg-pl-a@MONMOUTH-EMH3.ARMY.MIL
  184.                                            (908) 532-3817 (DSN) 992-3817
  185.       Reynolds, John W. (JWR46) EAAV-AP@SEOUL-EMH1.ARMY.MIL
  186.                                            (DSN) 723-3358
  187.       Reynolds, Joseph T. (JTR10)  JREYNOLDS@PAXRV-NES.NAVY.MIL
  188.                                        011-63-47-885-3194 (DSN) 885-3194
  189.       Reynolds, Joyce K. (JKR1) JKREY@ISI.EDU             (213) 822-1511
  190.       Reynolds, Keith (KR35)    keithr@SCO.CO             (408) 425-7222
  191.       Reynolds, Kenneth (KR94)                            (502) 454-2950
  192.       Reynolds, Kevin A. (KR39)    REYNOLDS@DUGWAY-EMH1.ARMY.MIL
  193.                                            (801) 831-5441 (DSN) 789-5441
  194.       Reynolds, Lee B. (LBR9)   reynolds@TECHNET.NM.ORG   (505) 345-6555
  195.  
  196.       a further lookup on Joyce Reynolds with this command line:
  197.  
  198.       whois JKR1
  199.  
  200.    returns:
  201.  
  202.       Reynolds, Joyce K. (JKR1)               JKREY@ISI.EDU
  203.          University of Southern California
  204.          Information Sciences Institute
  205.          4676 Admiralty Way
  206.          Marina del Rey, CA 90292
  207.          (310) 822-1511
  208.  
  209.          Record last updated on 07-Jan-91.
  210.  
  211.    The whois database also contains information about Domain Name System
  212.    (DNS) and has some information about hosts, major regional networks,
  213.    and large parts of the MILNET system.
  214.  
  215.    The WHOIS database is large enough and comprehensive enough to
  216.    exhibit many of the flaws of a large centralized database: a) As the
  217.    database is maintained on one machine, a processor bottleneck forces
  218.    slow response during times of peak querying activity, even if many of
  219.    these queries are unrelated, b) as the database is maintained on one
  220.    machine, a storage bottleneck forces the database administrators to
  221.    severely limit the amount of information which can be kept on each
  222.    entry in the database, c) all changes to the database have to be
  223.  
  224.  
  225.  
  226. DISI Working Group                                              [Page 4]
  227.  
  228. RFC 1309              Technical Overview of X.500             March 1992
  229.  
  230.  
  231.    mailed to a "hostmaster" and then physically reentered into the
  232.    database, increasing both the turnaround time and the likelihood for
  233.    a mistake in transcription.
  234.  
  235. 2.2.3 The Domain Name System
  236.  
  237.    The Domain Name System is used in the Internet to keep track of host
  238.    to IP address mapping. The basic mechanism is that each domain, such
  239.    as merit.edu or k-12.edu, is registered with the NIC, and at time of
  240.    registration, a primary and (perhaps) some secondary nameservers are
  241.    identified for that domain. Each of these nameservers must provide
  242.    host name to IP address mapping for each host in the domain. Thus,
  243.    the nameservice is supplied in a distributed fashion. It is also
  244.    possible to split a domain into subdomains, with a different
  245.    nameserver for each subdomain.
  246.  
  247.    Although in many cases one uses the DNS without being aware of it,
  248.    because humans prefer to remember names and not IP addresses, it is
  249.    possible to interactively query the DNS with the nslookup utility. A
  250.    sample session using the nslookup utility:
  251.  
  252.       home.merit.edu(1): nslookup
  253.       Default Server:  merit.edu
  254.       Address:  35.42.1.42
  255.  
  256.       > scanf.merit.edu
  257.       Server:  merit.edu
  258.       Address:  35.42.1.42
  259.  
  260.       Name:   scanf.merit.edu
  261.       Address: 35.42.1.92
  262.  
  263.       > 35.42.1.92
  264.       Server:  merit.edu
  265.       Address: 35.42.1.42
  266.  
  267.       Name:  [35.42.1.92]
  268.       Address: 35.42.1.92
  269.  
  270.    Thus, we can explicitly determine the address associated with a given
  271.    host.  Reverse name mapping is also possible with the DNS, as in this
  272.    example:
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. DISI Working Group                                              [Page 5]
  283.  
  284. RFC 1309              Technical Overview of X.500             March 1992
  285.  
  286.  
  287.       home.merit.edu(2): traceroute ans.net
  288.       traceroute to ans.net (147.225.1.2), 30 hops max, 40 byte packets
  289.         1 t3peer (35.1.1.33) 11 ms 5 ms 5 ms
  290.         2 enss (35.1.1.1) 6 ms 6 ms 6 ms
  291.               .................
  292.         9 192.77.154.1 (192.77.154.1) 51 ms 43 ms 49 ms
  293.        10 nis.ans.net (147.225.1.2) 53 ms 53 ms 46 ms
  294.  
  295.    At each hop of the traceroute, the program attempts to do a reverse
  296.    lookup through the DNS and displays the results when successful.
  297.  
  298.    Although the DNS has served superlatively for the purpose it was
  299.    developed, i.e. to allow maintenance of the namespace in a
  300.    distributed fashion, and to provide very rapid lookups in the
  301.    namespace, there are, of course, some limitations. Although there has
  302.    been some discussion of including other types of information in the
  303.    DNS, to find a given person at this time, assuming you know where she
  304.    works, you have to use a combination of the DNS and finger to even
  305.    make a stab at finding her. Also, the DNS has very limited search
  306.    capabilities right now. The lack of search capabilities alone shows
  307.    that we cannot provide a rich Directory Service through the DNS.
  308.  
  309. 3: THE X.500 MODEL OF DIRECTORY SERVICE
  310.  
  311.    X.500 is a CCITT protocol which is designed to build a distributed,
  312.    global directory.  It offers the following features:
  313.  
  314.    * Decentralized Maintenance:
  315.      Each site running X.500 is responsible ONLY for its local part
  316.      of the Directory, so updates and maintenance can be done instantly.
  317.  
  318.    * Powerful Searching Capabilities:
  319.      X.500 provides powerful searching facilities that allow users to
  320.      construct arbitrarily complex queries.
  321.  
  322.    * Single Global Namespace:
  323.      Much like the DNS, X.500 provides a single homogeneous namespace
  324.      to users.  The X.500 namespace is more flexible and expandable
  325.      than the DNS.
  326.  
  327.    * Structured Information Framework:
  328.      X.500 defines the information framework used in the directory,
  329.      allowing local extensions.
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. DISI Working Group                                              [Page 6]
  339.  
  340. RFC 1309              Technical Overview of X.500             March 1992
  341.  
  342.  
  343.    * Standards-Based Directory:
  344.      As X.500 can be used to build a standards-based directory,
  345.      applications which require directory information (e-mail,
  346.      automated resource locators, special-purpose directory tools)
  347.      can access a planet's worth of information in a uniform manner,
  348.      no matter where they are based or currently running.
  349.  
  350. 3.1 Acronym City, or How X.500 Works
  351.  
  352.    The '88 version of the X.500 standard talks about 3 models required
  353.    to build the X.500 Directory Service: the Directory Model, the
  354.    Information Model, and the Security Model. In this section, we will
  355.    provide a brief overview of the Directory and Information Models
  356.    sufficient to explain the vast functionality of X.500.
  357.  
  358. 3.1.1 The Information Model
  359.  
  360.    To illustrate the Information Model, we will first show how
  361.    information is held in the Directory, then we will show what types of
  362.    information can be held in the Directory, and then we will see how
  363.    the information is arranged so that we can retrieve the desired
  364.    pieces from the Directory.
  365.  
  366. 3.1.1.1 Entries
  367.  
  368.    The primary construct holding information in the Directory is the
  369.    "entry".  Each Directory entry contains information about one object;
  370.    for example, a person, a computer network, or an organization. Each
  371.    entry is built from a collection of "attributes", each of which holds
  372.    a single piece of information about the object. Some attributes which
  373.    might be used to build an entry for a person would be "surname",
  374.    "telephonenumber", "postaladdress", etc. Each attribute has an
  375.    associated "attribute syntax", which describes the type of data that
  376.    attribute contains, for example, photo data, a time code, or a string
  377.    of letters and numbers. As an example, let's look at part of an entry
  378.    for a person.
  379.  
  380.   Entry for John Smith contains:
  381.  
  382.     attribute ---> surName=              Smith  <--- attribute value
  383.              |---> telephoneNumber=   999-9999  <--- attribute value
  384.              |---> title=              Janitor  <--- attribute value
  385.                                 ...
  386.  
  387.    The attribute syntax for the surName attribute would be
  388.    CaseIgnoreString, which would tell X.500 that surName could contain
  389.    any string, and case would not matter; the attribute syntax for the
  390.    telephoneNumber attribute would be TelephoneNumber, which would
  391.  
  392.  
  393.  
  394. DISI Working Group                                              [Page 7]
  395.  
  396. RFC 1309              Technical Overview of X.500             March 1992
  397.  
  398.  
  399.    specify that telephoneNumber could contain a string composed of
  400.    digits, dashes, parenthesis, and a plus sign.  The attribute syntax
  401.    for the title attribute would also be CaseIgnoreString.  A good
  402.    analogy in database terms for what we've seen so far might be to
  403.    think of a Directory entry as a database record, an attribute as a
  404.    field in that record, and an attribute syntax as a field type
  405.    (decimal number, string) for a field in a record.
  406.  
  407. 3.1.1.2 Object Classes
  408.  
  409.    At this point in our description of the information model, we have no
  410.    way of knowing what type of object a given entry represents. X.500
  411.    uses the concept of an "object class" to specify that information,
  412.    and an attribute named "objectClass" which each entry contains to
  413.    specify to which object class(es) the entry belongs.
  414.  
  415.    Each object class in X.500 has a definition which lists the set of
  416.    mandatory attributes, which must be present, and a set of optional
  417.    attributes, which may be present, in an entry of that class. An given
  418.    object class A may be a subclass of another class B, in which case
  419.    object class A inherits all the mandatory and optional attributes of
  420.    B in addition to its own.
  421.  
  422.    The object classes in X.500 are arranged in a hierarchical manner
  423.    according to class inheritance; the following diagram shows a part of
  424.    the object class hierarchy.
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. DISI Working Group                                              [Page 8]
  451.  
  452. RFC 1309              Technical Overview of X.500             March 1992
  453.  
  454.  
  455.                           _____________
  456.                          |             | "top" has one mandatory
  457.                          | top         | attribute "objectClass",
  458.                          |_____________| and nooptional attributes.
  459.                           |     |    |
  460.                           |     |    | every other object class is a
  461.           ________________|     |    | subclass of "top"...
  462.           |                     |   ...
  463.     ______|________        _____|_______
  464.    |               |     |               |"organization" inherits one
  465.    | country       |     | organization  |mandatory attribute from
  466.    |_______________|     |_______________|"top", "objectClass"; adds one
  467.                                           more mandatory attribute "O"
  468.  "country" inherits one                   (for organization), and has
  469.  mandatory attribute from "top",          many optional attributes. Any
  470.  "objectClass", adds one more             subclass of "organization"
  471.  mandatory attribute "c" (for             would inherit all of the
  472.  country), and has two optional           mandatory and optional
  473.  attributes, "description" and            attributes from "organization"
  474.  "searchGuide". Any subclass of           including the attribute which
  475.  "country" would inherit all of the       "organization" inherited
  476.  mandatory and optional attributes        from "top".
  477.  of the "country" class, including
  478.  the attribute which "country"
  479.  inherited from "top".
  480.  
  481.                                Figure 1.
  482.  
  483.    One major benefit of the object class concept is that it is in many
  484.    cases very easy to create a new object class which is only a slight
  485.    modification or extension of a previous class. For example, if I have
  486.    already defined an object class for "person" which contains a
  487.    person's name, phone number, address, and fax number, I can easily
  488.    define an "Internet person" object class by defining "Internet
  489.    person" as a subclass of "person", with the additional optional
  490.    attribute of "e-mail address". Thus in my definition of the "Internet
  491.    Person" object class, all my "person" type attributes are inherited
  492.    from "person". There are other benefits which are beyond the scope of
  493.    this paper.
  494.  
  495. 3.1.1.3 X.500's namespace.
  496.  
  497.    X.500 hierarchically organizes the namespace in the Directory
  498.    Information Base (DIB); recall that this hierarchical organization is
  499.    called the Directory Information Tree (DIT).  Each entry in the DIB
  500.    occupies a certain location in the DIT. An entry which has no
  501.    children is called a leaf entry, an entry which has children is
  502.    called a non-leaf node. Each entry in the DIT contains one or more
  503.  
  504.  
  505.  
  506. DISI Working Group                                              [Page 9]
  507.  
  508. RFC 1309              Technical Overview of X.500             March 1992
  509.  
  510.  
  511.    attributes which together comprise the Relative Distinguished Name
  512.    (RDN) of that entry, there is a "root" entry (which has no
  513.    attributes, a special case) which forms the base node of the DIT. The
  514.    Distinguished Name of a specific entry is the sequence of RDNs of the
  515.    entries on the path from the root entry to the entry in question. A
  516.    diagram here will help to clarify this:
  517.  
  518. Level of DIT              Root            RDN      Distinguished Name
  519.  
  520. root                       *             nothing        { }
  521.                          / | \
  522. country (other          /  |  \
  523. things at this         /   |   \         c=us         {c=us}
  524. level)           c=gb    c=us    c=ca
  525.                         /  |  \
  526.                        /   |   \
  527.                       /    |    \
  528. organization      o=SRI  o=Merit  o=DEC  o=Merit      {c=us, o=Merit}
  529. (other things           /  |   \
  530. at this level)         /   |    \
  531.                       /    |     \
  532. Third level          cn=Chris Weider     cn=Chris Weider {c=us, o=Merit,
  533.                                                         cn=Chris Weider}
  534.  
  535.        Figure 2: Building a DN from RDNs (adapted from a
  536.           diagram in the X.500 (88) Blue Book)
  537.  
  538.    Each entry in this tree contains more attributes than have been shown
  539.    here, but in each case only one attribute for each entry has been
  540.    used for that entry's RDN. As noted above, any entry in the tree
  541.    could use more than one attribute to build its RDN. X.500 also allows
  542.    the use of alias names, so that the entry {c=us, o=Merit, cn=Chris
  543.    Weider} could be also found through an alias entry such as {c=us,
  544.    o=SRI, ou=FOX Project, cn=Drone 1} which would point to the first
  545.    entry.
  546.  
  547. 3.1.2 The Directory Model
  548.  
  549.    Now that we've seen what kinds of information can be kept in the
  550.    Directory, we should look at how the Directory stores this
  551.    information and how a Directory users accesses the information. There
  552.    are two components of this model: a Directory User Agent (DUA), which
  553.    accesses the Directory on behalf of a user, and the Directory System
  554.    Agent, which can be viewed as holding a particular subset of the DIB,
  555.    and can also provide an access point to the Directory for a DUA.
  556.  
  557.    Now, the entire DIB is distributed through the world-wide collection
  558.    of DSAs which form the Directory, and the DSAs employ two techniques
  559.  
  560.  
  561.  
  562. DISI Working Group                                             [Page 10]
  563.  
  564. RFC 1309              Technical Overview of X.500             March 1992
  565.  
  566.  
  567.    to allow this distribution to be transparent to the user, called
  568.    "chaining" and "referral".  The details of these two techniques would
  569.    take up another page, so it suffices to say that to each user, it
  570.    appears that the entire global directory is on her desktop. (Of
  571.    course, if the information requested is on the other side of the
  572.    world, it may seem that the desktop directory is a bit slow for that
  573.    request...)
  574.  
  575. 3.2 The functionality of X.500
  576.  
  577.    To describe the functionality of X.500, we will need to separate
  578.    three stages in the evolution of X.500: 1) the 1988 standard, 2)
  579.    X.500 as implemented in QUIPU, and 3) the (proposed) 1992 standard.
  580.    We will list some of the features described in the 1988 standard,
  581.    show how they were implemented in QUIPU, and discuss where the 1992
  582.    standard will take us.  The QUIPU implementation was chosen because
  583.    a) it is widely used in the U.S. and European Directory Services
  584.    Pilot projects, and b) it works well. For a survey of other X.500
  585.    implementations and a catalogue of DUAs, see [Lang].
  586.  
  587. 3.2.1 Functionality in X.500 (88)
  588.  
  589.    There are a number of advantages that the X.500 Directory accrues
  590.    simply by virtue of the fact that it is distributed, not limited to a
  591.    single machine. Among these are:
  592.  
  593.    * An enormously large potential namespace.
  594.      Since the Directory is not limited to a single machine, many
  595.      hundreds of machines can be used to store Directory entries.
  596.  
  597.    * The ability to allow local administration of local data.
  598.      An organization or group can run a local DSA to master their
  599.      information, facilitating much more accurate data throughout
  600.      the Directory.
  601.  
  602.    The functionality built into the X.500(88) standard includes:
  603.  
  604.    * Advanced searching capabilities.
  605.      The Directory supports arbitrarily complex searches at an
  606.      attribute level. As the object classes a specific entry
  607.      belongs to is maintained in the objectClass attribute, this
  608.      also allows Directory searches for specific types of objects.
  609.      Thus, one could search the c=US subtree for anyone with a last
  610.      name beginning with S, who also has either a fax number in the
  611.      (313) area code or an e-mail address ending in umich.edu.
  612.      This feature of X.500 also helps to provide the basic
  613.      functionality for a Yellow Pages service.
  614.  
  615.  
  616.  
  617.  
  618. DISI Working Group                                             [Page 11]
  619.  
  620. RFC 1309              Technical Overview of X.500             March 1992
  621.  
  622.  
  623.    * A uniform namespace with local extensibility.
  624.      The Directory provides a uniform namespace, but local
  625.      specialized directories can also be implemented.  Locally
  626.      defined extensions can include new object classes, new
  627.      attributes, and new attribute types.
  628.  
  629.    * Security issues.
  630.      The X.500 (88) standards define two types of security for
  631.      Directory data: Simple Authentication (which uses passwords),
  632.      and Strong Authentication (which uses cryptographic keys).
  633.      Simple authentication has been widely implemented, strong
  634.      authentication has been less widely implemented.  Each of
  635.      these authentication techniques are invoked when a user or
  636.      process attempts a Directory operation through a DUA.
  637.  
  638.    In addition to the global benefits of the X.500 standard, there are
  639.    many local benefits. One can use their local DSA for company or
  640.    campus wide directory services; for example, the University of
  641.    Michigan is providing all the campus directory services through
  642.    X.500. The DUAs are available for a wide range of platforms,
  643.    including X-Windows systems and Macintoshes.
  644.  
  645. 3.2.2 Functionality added by QUIPU.
  646.  
  647.    Functionality beyond the X.500 (88) standard implemented by QUIPU
  648.    includes:
  649.  
  650.    * Access control lists.
  651.      An access control list is a way to provide security for each
  652.      attribute of an entry.  For example, each attribute in a given
  653.      entry can be permitted for detect, compare, read, and modify
  654.      permissions based on the reader's membership in various groups.
  655.      For example, one can specify that some information in a given
  656.      entry is public, some can be read only by members of the
  657.      organization, and some can only be modified by the owner of
  658.      the entry.
  659.  
  660.    * Replication.
  661.      Replication provides a method whereby frequently accessed
  662.      information in a DSA other than the local one can be kept by
  663.      the local DSA on a "slave" basis, with updates of the "slave"
  664.      data provided automatically by QUIPU from the "master" data
  665.      residing on the foreign DSA.  This provides alternate access
  666.      points to that data, and can make searches and retrievals
  667.      more rapid as there is much less overhead in the form or
  668.      network transport.
  669.  
  670.  
  671.  
  672.  
  673.  
  674. DISI Working Group                                             [Page 12]
  675.  
  676. RFC 1309              Technical Overview of X.500             March 1992
  677.  
  678.  
  679. 3.3 Current limitations of the X.500 standard and implementations.
  680.  
  681.    As flexible and forward looking as X.500 is, it certainly was not
  682.    designed to solve everyone's needs for all time to come. X.500 is not
  683.    a general purpose database, nor is it a Data Base Management System
  684.    (DBMS). X.500 defines no standards for output formats, and it
  685.    certainly doesn't have a report generation capability. The technical
  686.    mechanisms are not yet in place for the Directory to contain
  687.    information about itself, thus new attributes and new attribute types
  688.    are rather slowly distributed (by hand).
  689.  
  690.    Searches can be slow, for two reasons: a) searches across a widely
  691.    distributed portion of the namespace (c=US, for example) has a delay
  692.    which is partially caused by network transmission times, and can be
  693.    compounded by implementations that cache the partial search returns
  694.    until everyone has reported back, and b) some implementations are
  695.    slow at searching anyway, and this is very sensitive to such things
  696.    as processor speed and available swap space.  Another implementation
  697.    "problem" is a tradeoff with security for the Directory: most
  698.    implementations have an administrative limit on the amount of
  699.    information which can be returned for a specific search.  For
  700.    example, if a search returns 1000 hits, 20 of those might be
  701.    displayed, with the rest lost. Thus a person performing a large
  702.    search might have to perform a number of small searches.  This was
  703.    implemented because an organization might want to make it hard to
  704.    "troll" for the organization's entire database.
  705.  
  706.    Also, there is at the moment no clear consensus on the ideal shape of
  707.    the DIT, or on the idea structure of the object tree.  This can make
  708.    it hard to add to the current corpus of X.500 work, and the number of
  709.    RFCs on various aspects of the X.500 deployment is growing monthly.
  710.  
  711.    Despite this, however, X.500 is very good at what it was designed to
  712.    do; i.e., to provide primary directory services and "resource
  713.    location" for a wide band oftypes of information.
  714.  
  715. 3.4 Things to be added in X.500 (92).
  716.  
  717.    The 1988 version of the X.500 standard proved to be quite sufficient
  718.    to start building a Directory Service. However, many of the new
  719.    functions implemented in QUIPU were necessary if the Directory were
  720.    to function in a reasonable manner. X.500 (92) will include
  721.    formalized and standardized versions of those advances, including
  722.  
  723.    * A formalized replication procedure.
  724.  
  725.    * Enhanced searching capacities.
  726.  
  727.  
  728.  
  729.  
  730. DISI Working Group                                             [Page 13]
  731.  
  732. RFC 1309              Technical Overview of X.500             March 1992
  733.  
  734.  
  735.    * Formalization of access control mechanisms, including access
  736.      control lists.
  737.  
  738.    Each of these will provide a richer Directory, but you don't have to
  739.    wait for them! You can become part of the Directory today!
  740.  
  741. 4: WHAT X.500 CAN DO FOR YOU TODAY
  742.  
  743. 4.1 Current applications of X.500
  744.  
  745.    X.500 is filling Directory Services needs in a large number of
  746.    countries.  As a directory to locate people, it is provided in the
  747.    U.S. as the White Pages Pilot Project, run by PSI, and in Europe
  748.    under the PARADISE Project as a series of nation-wide pilots.  It is
  749.    also being used by the FOX Project in the United States to provide
  750.    WHOIS services for people and networks, and to provide directories of
  751.    objects as disparate as NIC Profiles and a pilot K-12 Educators
  752.    directory. It is also being investigated for its ability to provide
  753.    resource location facilities and to provide source location for WAIS
  754.    servers. In fact, in almost every area where one could imagine
  755.    needing a directory service (particularly for distributed directory
  756.    services), X.500 is either providing those services or being expanded
  757.    to provide those services.
  758.  
  759.    In particular, X.500 was envisioned by its creators as providing
  760.    directory services for electronic mail, specifically for X.400. It is
  761.    being used in this fashion today at the University of Michigan:
  762.    everyone at the University has a unified mail address, e.g.
  763.    Chris.Weider@umich.edu. An X.500 server then reroutes that mail to
  764.    the appropriate user's real mail address in a transparent fashion.
  765.    Similarly, Sprint is using X.500 to administrate the address space
  766.    for its internal X.400 mail systems.
  767.  
  768.    Those of us working on X.500 feel that X.500's strengths lie in
  769.    providing directory services for people and objects, and for
  770.    providing primary resource location for a large number of online
  771.    services. We think that X.500 is a major component (though not the
  772.    only one) of a global Yellow Pages service. We would also like to
  773.    encourage each of you to join your national pilot projects; the more
  774.    coverage we can get, the easier you will be able to find the people
  775.    you need to contact.
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786. DISI Working Group                                             [Page 14]
  787.  
  788. RFC 1309              Technical Overview of X.500             March 1992
  789.  
  790.  
  791. 5.  For Further Information
  792.  
  793.    For further information, the authors recommend the following
  794.    documents:
  795.  
  796.       Weider, C., and J. Reynolds, "Executive Introduction to Directory
  797.       Services Using the X.500 Protocol", FYI 13, RFC 1308, ANS, ISI,
  798.       March 1992.
  799.  
  800.       Lang, R., and R. Wright, Editors, "A Catalog of Available X.500
  801.       Implementations", FYI 11, RFC 1292, SRI International, Lawrence
  802.       Berkeley Laboratory, January 1992.
  803.  
  804.       Barker, P., and S. Hardcastle-Kille, "The COSINE and Internet
  805.       X.500 Schema", RFC 1274, University College London, November 1991.
  806.  
  807.       Hardcastle-Kille, S., "Replication Requirements to provide an
  808.       Internet Directory using X.500", RFC 1275, University College
  809.       London, November, 1991.
  810.  
  811.       Hardcastle-Kille, S., "Replication and Distributed Operations
  812.       extensions to provide an Internet Directory using X.500", RFC
  813.       1276, University College London, November 1991.
  814.  
  815.       Hardcastle-Kille, S., "Encoding Network Addresses to support
  816.       operation over non-OSI lower layers", RFC 1277, University College
  817.       London, November 1991.
  818.  
  819.       Hardcastle-Kille, S., " A string encoding of Presentation
  820.       Address", RFC 1278, University College London, November 1991.
  821.  
  822.       Hardcastle-Kille, S., "X.500 and Domains", RFC 1279, University
  823.       College London, November 1991.
  824.  
  825. 6.  Security Considerations
  826.  
  827.       Security issues are discussed in section 3.
  828.  
  829.  
  830.  
  831.  
  832.  
  833.  
  834.  
  835.  
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842. DISI Working Group                                             [Page 15]
  843.  
  844. RFC 1309              Technical Overview of X.500             March 1992
  845.  
  846.  
  847. 7.  Authors' Addresses
  848.  
  849.       Chris Weider
  850.       Advanced Network and Services, Inc.
  851.       2901 Hubbard G-1
  852.       Ann Arbor, MI 48105-2437
  853.  
  854.       Phone (313) 663-2482
  855.       E-mail: weider@ans.net
  856.  
  857.  
  858.       Joyce K. Reynolds
  859.       Information Sciences Institute
  860.       University of Southern California
  861.       4676 Admirality Way
  862.       Marina del Rey, CA 90292
  863.  
  864.       Phone: (310) 822-1511
  865.       EMail: jkrey@isi.edu
  866.  
  867.  
  868.       Sergio Heker
  869.       JvNCnet
  870.       Princeton University
  871.       6 von Neumann Hall
  872.       Princeton, NJ 08544
  873.  
  874.       Phone: (609) 258-2400
  875.       Email: heker@nisc.jvnc.net
  876.  
  877.  
  878.  
  879.  
  880.  
  881.  
  882.  
  883.  
  884.  
  885.  
  886.  
  887.  
  888.  
  889.  
  890.  
  891.  
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898. DISI Working Group                                             [Page 16]
  899.